Intermediary Nodes or proxies are important and necessary in many deployments of various application layer protocols such as e.g. Hypertext Transfer Protocol (HTTP), Hypertext Transfer Protocol Secure (HTTPS), Message Session Relay Protocol (MSRP), Session Initiation Protocol (SIP), Constrained Application Protocol (CoAP), etc. One of the most important use cases are HTTP proxies which are universally deployed in e.g. enterprises, operator networks, hotels, and airports. Another example is MSRP proxies which are abundant in MSRP deployments.
Intermediary Nodes, which may alternatively be referred to as intermediate nodes, perform services, such as e.g. traffic optimization, caching, antivirus protection, downlink content screening and filtering in e.g. schools, uplink content screening and filtering in enterprises, and message storage in the case of messaging protocols, such as e.g. MSRP.
There exist solutions for the Secure Real-time Transport Protocol (SRTP), such as e.g. in WO2010/003713 A1. However, these known solutions are not applicable for the mentioned scenario, since these solutions target another trust model where the proxy is simply not trusted to access content at all. Thus, in these solutions the proxy will not gain any access to desired content. Secondly, the aforementioned SRTP solutions use tunnel-in-tunnel and multiplexing mechanisms with additional (in our case unwanted) overhead. Thirdly, these types of solutions are SRTP-specific and do not work with TLS.
Known 3GPP IMS related mechanisms as disclosed in 3GPP TS 33.828, by which an IMS network may add/replace a Client offer for e2e security with a “hop-by-hop” security, do not offer any control or consent from the endpoints. Also, they are tightly integrated with IMS protocols (SIP, SRTP) and do not work for TLS.
Many of these application layer protocols are protected with Transport Layer Security (TLS), or Datagram Transport Layer Security (DTLS), since they can provide strong security and represent “standard” ways to protect TCP or UDP traffic implemented in most Clients and Servers. In most cases TLS or DTLS is setup before the application protocol is used. With TLS, we hereby mean all versions of TLS and its derivatives like DTLS.
When the communication is not protected with TLS, an Intermediary Node may in most cases insert itself into the communication path, i.e. by interposing itself it can potentially eavesdrop, inject, or modify traffic between sender and receiver, causing what can be referred to as “traffic intervention”. When TLS is used, each Intermediary Node has only three choices, let the Client setup TLS end-to-end with the Server, break the TLS security model, or attempt to block the traffic.
Common to the three options is that in most cases the Client and the Server are not aware that there is any Intermediary Node in the communication path. If an Intermediary Node has “silently” broken the TLS (end-to-end) security model, how does the TLS Client/Server know that their traffic is not subject to unauthorized access?
Furthermore, one or more “friendly” Intermediary Nodes in the communication path still have no way of making their presence known to the TLS Client or TLS Server even if it wants to. As neither the Client nor the Server is aware of the Intermediary Node/s and their identities, they cannot include them in its communication, meaning the Intermediary Node/s must either resort to block the traffic, i.e. disabling the Client/Server communication, or it can let the traffic pass, but then it cannot fulfil the service as intended.
Even though we have referred to TLS Clients and TLS Servers above, it will be evident from the following text that corresponding, intermediary related problems can be relevant also in scenarios where TLS is, not used, or at least initially not used.